Designing and fabricating electronic systems typically involves many steps, known as a “design flow.” The particular steps of a design flow often are dependent upon the type of electronic system, its complexity, the design team, and the fabricator or foundry that will manufacture the electronic system. Typically, software and hardware “tools” verify the design at various stages of the design flow by running software simulators and/or hardware emulators, and errors in the design are corrected or the design is otherwise improved.
Several steps are common to most design flows for electronic systems. Initially, the specification for a new electronic system is transformed into a logical design, sometimes referred to as a register transfer level (RTL) description of the electronic system. With this logical design, the electronic system can be described in terms of both the exchange of signals between hardware registers and the logical operations that can be performed on those signals. The logical design typically employs a Hardware Design Language (HDL), such as the Verilog, Very high speed integrated circuit Hardware Design Language (VHDL), or the like. The logic of the electronic system can be analyzed to confirm that it will accurately perform the functions desired for the electronic system. This analysis is sometimes referred to as “functional verification.”
Functional verification often begins with a circuit design coded at a register transfer level (RTL), which can be simulated by a design verification tool. A designer, for example, utilizing the design verification tool can simulate circuit design and provide test stimulus to the simulated circuit design with a test bench. The designer also can utilize the design verification tool to execute assertion statements, which can compare values of simulated signals or other items in the simulated circuit design with conditions in the assertion statements. When the execution of the assertion statements indicate the simulated circuit design operates differently than expected, sometimes called an assertion statement failure, the designer can attempt to debug the circuit design. The design verification tool can record signal states and transitions of the circuit design, often called waveform data, which the designer can review in an attempt to identify a “bug” in the circuit design. The designer typically can utilize a debug tool to review the recorded waveform data in an attempt to locate and address the circuit design failure.
In some instances, the assertion statement failures may not identify a “bug” in the circuit design, but rather be a result of a defect in the assertion statement itself. Thus, the designer may spend time attempting to debug the circuit design when the error is actually located in the assertion statement.
Designers of the circuit design often debug failed assertion statements by introducing mutations to the failed assertion statements or by utilizing the recorded waveform data to evaluate the sequence items and conditions. The former debugging technique generates a large number of mutated assertion statements that can be filtered via a small-time-period simulation trace before being verified against simulation results. A resulting final list of mutated assertion statements can be consistent with the simulated behavior of the circuit design. The latter debugging technique depends on manual evaluations of assertion statement conditions to locate an error. Many design verification tools stop checking conditions in assertion statements during simulation of the circuit design in response to a violation of at least one of those conditions. Thus, once an error in an assertion statement is located and fixed, the designer re-runs a simulation of the circuit design to validate and help ensure that no other errors arise, for example, when a detection of an error was blocked by the previously detected error. The re-running of the simulation may be repeated iteratively until all errors in the assertion statements have been fixed.